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Abstract Text (1) : 

Under the situation in a network including a transmitter and a receiver in which a 
transmitter converts a non - compressed packet to be transmitted as a full -header 
packet including a full header or a header - compressed packet inclujding a compressed 
header, and sends the converted packet to the receiver, the transmitter sends at 
least an important packet in the non -compressed packet to be transmitted as a full- 
header packet. The important packet means for example, a packet containing the data 
serving an important role when the data terminal eventually receiving each packet 
reproduces the audio and/or image in accordance with the data in each packet. 

Brief Summary Text (7) : 

FIG. 13A shows contents of an RTP header, UDP header, and IP header (hereafter, 
referred to as "RTP/UDP/IP headers") attached to data, such as audio and video 
data, to be transmitted according to the RTP, UDP and IP. Hereinafter, a packet 
including the RTP/UDP/IP headers is called an IP packet. 

Brief Summary Text (8) : 

As shown in the drawing, the IP header needs 20 bytes, the UDP header needs 8 
bytes, and the RTP header needs 12 bytes, thus the total amount of RTP/UDP/IP 
headers reaches 4 0 bytes, in contrast, video data contained in one IP packet 
comprises, for example, about 50 bytes. For transmitting such image data in the 
form of packets, the overhead reaches therefore no less than 44 percent. Similarly, 
for transmitting audio data which comprises 2 0 bytes in one packet, the overhead 
reaches as much as 66 percent. Since a practical transmission needs headers for 
other layers to be added, the whole headers occupy a large percentage of one 
packet, thereby causing a drawback of reducing efficiency in communication. 

Brief Summary Text (9) : 

As one technique to overcome the drawback, the RFC2508 issued by the IETF shows an 
RTP compression protocol to compress the RTP/UDP/IP headers. The RTP compression 
protocol permits the RTP/UDP/IP headers shown in the FIG. 13A to be compressed into 
a header exemplified in FIG. 13B (hereinafter referred to as a " compressed 
header"). This compression will be detailed as follows. 

Brief Summary Text (10) : 

The method of the compression is applied between two nodes on a network through 
which packets are transmitted among a plurality of data terminals, for example. 
More specifically, of the two nodes, one node (hereinafter referred to as a "sender 
node") converts the RTP/UDP/IP headers of one part of the IP packets communicated 
among the data terminals into a compressed header, and transmits it, as a header^ 
compressed packet, to the other node (hereinafter referred to as a "receiver 
node") . Concurrently, the sender node transmits the RTP/UDP/IP headers of the other 



http://jupiter:9000^in/gate.exe?f=doc&state=jnktgg.25.1&ESNAM 10/11/2006 



Record Display Form 



Page 2 of 18 



part of the IP packets to the receiver node, as a full -header packet without any 
compression . The r eceiver node decompre sses (i.e., restoration) to an IP packet th e 
header -compressed packet or the full -header pacJcet received from the sender node 7 
and sends it to the next node or a receiver data terminal. The full header is a 
header in which lengths included in the RTP/UDP/IP headers shown in FIG. 13A are 
replaced by information including a CONTEXT_ID for identifying the RTP connection 
and a link sequence number link seq, a serial number, given in the order of 
transmission from the sender node. 

Brief Summary Text (11) : 

The content of the compressed header shown in FIG. 13B will now be explained. The 
data of sections with dense hatching applied in the RTP/UDP/IP headers in FIG. 13A, 
which includes a version number (V) written in the IP header and the payload type 
written in the RTP header, are constant data (hereinafter referred to as "static 
fields") for each packet to be transmitted from the sender node. Hence, as 
illustrated in FIG. 13B, the compressed header does not include data of the static 
fields. When the sender node sends the first IP packet of the packet stream to the 
receiver node, it sends a full -header packet which has a full header including the 
static fields. After this, the sender node converts the RTP/UDP/IP headers of the 
succeeding IP packets into a compressed header with no static fields included. The 
thus -converted compressed header is sent to the receiver node as a header^ 
compressed packet . W hen the^receiver node^receiv es the full header packet 
cqrresporid-iri a^to t h e fi.rs.t_IP packet, the„ recei_ve r_nod e res tores ^rie' received 
RTP/UDP/IP headers with reference tQ—the . full header__in the first received fu ll - 
header packet, and writ_es the thus de_c_Qm pres.aed,h eadex s_in, to„ , an in te r r naJL-s_tpxage_ , f 
device. After this, the receiver node uses the static fields of the RTP/UDP/IP 
headers so as to restore the static fields of the compressed header in the header^ 
compressed packets that will be received successively after the first packet. 

Brief Summary Text (12) : 

The data in the static fields are not always constant over all the IP packets, but 
might be changed depending on a certain IP packet. If such a change occurs in a 
certain IP packet, the sender node will transmit a full header packet including a 
full header corresponding to the RTP /UDP/IP header of the IP packet to the receiver 
node, without compression . 

Brief Summary Text (13) : 

The data in the sections with no hatching applied in the RTP/UDP/IP headers shown 
in FIG. 13A include the sequence number and timestamp of the RTP header as well as 
the ID of the IP header. The timestamp indicates the time at which a packet is 
transmitted or generated. Such data are expected to have constant difference values 
(changed amounts) between successive two IP packets transmitted in turn. 
Hereinafter, fields providing such data are referred to as "delta fields." As shown 
in FIG. 13B, the basic compressed header does not include the data in the delta 
fields. As described above, the receiver node — M hinh hoi dA -. R .XP./. U Dial3^B-4^ade^s^EL, — 
its storage device , adds difference values , wh ich have _,been prey juuisl.y^ c ±>.ta i ne,c L _ 
respectively to the values in the correspqndin g_d elta fields of th.e stored 
RTP/UDP/IP headers, thus being able to decompress delta fields . ox l — compressed 
he ade r s~ ' whi chwiTTconse cut i ve ly be r e c e 1 ved^therea f t e r . 

Brief Summary Text (14) : 

However, it is not always true that the difference values in the delta fields are 
constant between all the IP packets. There are some cases where changes are made to 
their difference values. In such cases, changed difference values have to be 
notified to the receiver node. The receiver node is able to restore the contents in 
the delta fields contained in the RTP/UDP/IP headers of each header - compressed 
packet which will be received thereafter, with reference to the contents of the 
RTP/UDP/IP headers held in the storage device and the newly notified difference 
values. For this purpose, the compressed header shown in FIG. 13A has flags S, T 
and I that represent whether the difference values in the delta fields are changed 
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or not. If any difference values are changed, the new difference values are added 
to the compressed header, as shown by the dotted lines in FIG. 13B. Practically, if 
there is a change in the difference value of the sequence number of the RTP header, 
"1" is set to the flag S and a sequence number difference value (de.lta RTP 
sequence) showing the new difference value of the sequence number is added to the 
compressed header, as shown by the dotted line in FIG. 13B. Similarly, if there is 
a change in the difference value of the timestamp of the RTP header, "1" is set to 
the flag T, and a timestamp difference value (delta RTP timestamp) showing the new 
difference value of the timestamp is included in the compressed header, as shown by 
the dotted line in FIG. 13B. Further, if there is a change in the difference value 
of the ID of the IP header, "1" is set to the flag I, and an ID difference value 
(delta IP ID) showing the new difference value of the ID is attached to the 
compressed header. 

Brief Summary Text (15) : 

As shown in FIG. 13B, the compressed header further includes the CONTEXT_ID and 
link_seq, like the full header. The receiver node decompresses the compressed 
header in compliance with the contents of RTP/UDP/IP headers specified by the 
CONTEXT_ID. The receiver node refers to the link sequence number link_seq of each 
packet (header - compressed packet or full -header packet) sent in order from the 
sender node. When it is found that some link sequence numbers are dropped, the 
receiver node determines that the packets are lost between the transmitter and 
receiver nodes . 

Brief Summary Text (16) : 

Referring to FIG. 14, procedures made for packet transmission between the 
transmitter and receiver nodes will now be described. In FIG. 14, a field A shows a 
static field of the RTP/UDP/IP headers (i.e., any of the data with the dense 
hatching applied in FIG. 13A) , and a field B shows a delta field .(i.e., any of the 
data with no hatching applied in FIG. 13A) . Further, in FIG. 14, "F" represents a 
full-header packet, while "C" represents a header - compressed packet. 

Brief Summary Text (18) : 

The sender node then converts the RTP/UDP/IP headers in an IP packet b received 
after the IP packet a into a compressed header, and transmits the packet b with the 
compressed header to the receiver node (refer to "0P2" in FIG. 14) . In the 
compressed header in the header - compressed packet, a difference value . DELTA. B(=l) 
between a value [1] in the delta fields B of the packet b and a value [0] in the 
delta fields B of the last packet a is added, while a value of "1" is set to the 
flags (flags S, T and I shown in FIG. 13B) that represent changes or non-changes in 
the difference value . 



Brief Summary Text (19) : 

The receiver node, which received the header - compressed packet b, obtains the delta 
fields B of the compressed headers of the header -compressed packet b by adding the 
difference value . DELTA. B notified in this packet to the values of the delta fields 
B of the RTP/UDP/IP headers of the last IP packet a stored in the internal storage. 
The receiver node then transmits an IP packet b having both of the , RTP/UDP/IP 
headers, which include the delta fields B and the static fields A of the RTP/UDP/IP 
headers of the IP packet a, and the RTP payload. The RTP/UDP/IP headers referred in 
decompressing the IP packet b (in this case, the RTP/UDP/IP headers extracted from 
the last IP packet a) is specified by the CONTEXT__ID of the header -compressed 
packet b. The RTP/UDP/IP headers of the IP packet b and the difference 
value .DELTA. B notified in this packet are also stored in the internal storage. 

Brief Summary Text (20) : 

When next receiving an IP packet c, the sender node calculates a difference value 
b etween values of delta fiel ds B of both of the IP packet 'c and the last IP packet ~ 
b. Th e difference value" :jj£fLTA .JB is [1] ( =3-2) in this case , ' which is the same as 
the previous one notified to the receiver Jiode last time. Therefore, there is no™^ 
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need to newly notify the receiver node of the unchanged difference value. Hence, 
the- sender node transmits to the receiver node a header - compressed packet c having 
a compressed header with no difference value (i.e., information shown by the dotted 
line in FIG. 13B (refer to "0P3" in FIG. 14) . The receiver node that received this 
header -compressed packet c adds the stored difference value .DELTA. B to the delta 
fields B of the previous packet b^ thereby decompressing the delta fields B of this 
compressed header of the header -compressed packet. Then the receiver node sends an 
IP packet c composed of both RTP/UDP/IP headers, including the decompressed value 
and the static fields A extracted from the full header of the full -header packet a, 
and RTP payload. The next packet d is processed similarly. 

Brief Summary Text (21) : 

The delta fields B of an IP packet e next received by the sender node is [5] in 
value, of which difference value from the delta fields B of the last IP packet d is 
[2] . When the difference value . DELTA. B is changed in this way, the sender node 
transmits a header - compressed packet e having a compressed header in which the 
changed new difference value is added and the corresponding flag is set to [1] . The 
receiver node adds the newly notified difference value to the values of the delta 
fields B of the IP packet d so as to decompress the delta fields B of the packet e~ 
then transmits an IP packet containing the decompressed delta fields B. 

Brief Summary Text (22) : 

The sender node then receives an IP packet g, which is different in the static 
field A from the last IP packet e. Thus, in this case, the sender node does not , 
compress the RTP/UDP/IP headers of this IP packet and transmits a full -header f 1 
packet g having a full header in which the lengths in the RTP/UDP/IP headers of the 
packet g is replaced by the CONTEXT_ID and link_seq. The receiver node that \ 
received this full -header packet g converts the full header into the RTP /UDP/IP \ 
headers and memorizes them in the internal storage. \ > 

Brief Summary Text (23) : 

The header compression method ruled by the RFC2508 has been described above 
(hereinafter referred to as a "method A") . However, this compression method has 
been suffering from some drawbacks, which will be described as follows. 

Brief Summary Text (24) : 

For instance, as shown in FIG. 15, an assumption is made that the header -compressed 
packet c is lost between the transmitter and receiver nodes for some reason. As 
described above, when decompressing the packet d, the receiver node adds the 
difference value . DELTA. B to the delta fields B of the IP packet c to decompress 
the delta fields B of the IP packet d. As a result, when the header - compressed 
packet c is lost, it is impossible to decompress the delta fields B of the header^ 
compressed packet d. The receiver node is therefore forced to discard packets d, e 
and f shown in FIG. 15, which are received until the next full -header packet g. In 
other words, the loss of the packets causes consecutive losses of some other 
packets, which leads to reducing a throughput compared to a method in which the 
header compression is not involved. In particular, in cases the transmitter and 
receiver nodes are connected by a wireless link, a packet is likely to be lost in 
the wireless link. If such a loss occurs, some other packets are frequently 
discarded at the receiver node. As a technique to resolve such a problem, the RFC 
2507 and 2508 issued by the IETF and the Internet -Draft provide the following 
methods . 

Brief Summary Text (26) : 

In the case of the foregoing conventional method A, the sender node transmits a 
full-header packet only when the static fields of a header change in value. In 
contrast, as shown in FIG. 16, this method 1 selects several IP packets to be 
transmitted every predetermined number of packets, regardless of whether the static 
fields changes in value or not. And the selected IP packets are converted to the 
full header packets with full headers and the full header packets are transmitted 
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to the receiver node, while the remaining IP packets are converted to header^ 
compressed packet with compressed headers and the header -compressed packets are 
transmitted to the receiver node. In the method A, since , full-header packets are 
not transmitted to the receiver node as long as their static fields do not change 
in value, all the packets transmitted after the occurrence of loss of a packet are 
discarded. In contrast, the present method 1 allows a full -header packet to be 
transmitted at intervals, so that it has the advantage that the number of packets 
discarded owing to the loss of the packets can be lowered. However, the present 
method 1 has trade-offs that a longer period for transmitting full -header packets 
results in that the number of packets discarded is raised, whilst a shorter period 
for transmitting full -header packets results in that a large number of full-header 
packets with large overheads are transmitted, reducing efficiency in communication 



Brief Summary Text (30) : 

According to the present method 3, the compressed headers of header -compressed 
packets received after the loss* of a certain packet are decompressed using the 
RTP/UDP/IP headers decompressed most lately before the occurrence of loss of the 
packet. For example, as shown in FIG. 18, it is assumed that after a packet b is 
received in order, a packet c is lost, and then a packet d is received in order. In 
this situation, when a difference value . DELTA. B is unchanged in value over the 
packets b to d, the delta fields B of the packet d can be calculated by adding a 
value of double . DELTA. B to the delta fields B of the packet b. Moreover, the 
present method needs the UDP checksum included in a compressed header (refer to 
FIG. 13B) , so that the UDP checksum is used to determine if packets were 
decompressed correctly. However, as shown in FIG. 18, in cases where a packet k is 
lost and difference values . DELTA. B of the delta fields between packets and k 
change, there is the problem that a packet 1 received immediately after the packet 
loss cannot be decompressed correctly. In particular, in the case that packets are 
communicated via a wireless link, there is a possibility that packets are lost in 
sequence (namely, over a long interval) . Under such a situation, it is considered 
that difference values .DELTA. B are likely to change for a large number of lost 
packets. Therefore the foregoing problem is amplified. 

Brief Summary Text ' (32) : . 

According to the present method 4, the difference value .DELTA. B can be estimated 
on a characteristic of a media through which packets are transmitted. For example, 
in the case of FIG. 19, it is assumed that packets g and b are lost and difference 
values . DELTA. B between the packets g and h change. In this case, changes in the 
difference values .DELTA. B are estimated on a characteristic of a media through 
which packets are transmitted, and a packet can be decompressed through addition of 
the estimated difference value . DELTA. B to the packet f . Additionally, the present 
method uses an error detecting code (CRC) to confirm if the decompression is 
performed correctly or not. Thus, even if the difference value . DELTA. B changes, 
the present method enables packets received after the loss of a certain packet to 
be decompressed. However, the present method involves a difficulty in how the 
difference value .DELTA. B is estimated. 

Brief Summary Text (33) : 

As described above, although a variety of techniques have been proposed to 
efficiently perform data communication even when RTP/UDP/IP headers of IP packets 
are compressed, any technique has some drawbacks. Thus, it is a present situation 
that there is a limitation in effectively reducing the number of packets to be 
discarded owing to the loss of a certain packet that has been caused between the 
transmitter and receiver nodes. That is to say, loss of a part of packets during 
the packet transmission between the transmitter and the receiver nodes causes loss 
of the other packets in the receiver node. This causes great damage on the data 
processing using the packets received by the receiver data terminal (for example, 
display of image or replay of music using the received packets) . 



http://jupiter:9000/bin/gate^^ 10/11/2006 



Record Display Form 



Page 6 of 18 



Brief Summary Text (35) : 

The present invention has been made in view of the foregoing circumstances. An 
object of the present invention is to provide a packet transmitting method, a 
relaying device and a data terminal capable of effectively reducing the number of 
packets to be discarded due to the loss of a certain packet, even if headers of 
packets to be transmitted and received are compressed . 

Brief Summary Text (36) : 

According to one aspect of the present invention, an object of the present 
invention is achieved by a packet transmitting method for transmitting packets from 
a sender node to a receiver node through a network, comprising the steps of 
conversion by a communication apparatus provided on the sender node, for converting 
non - compressed packets to be transmitted into either a refresh-header packet with a 
refresh header containing information enough to be decompressed correctly and 
recover synchronization at the receiver node or a header - compressed packet with a 
compressed header containing less information than the refresh header, so that some 
of the non - compressed packets are converted into the refresh header packets as long 
as the packets are important packets; and transmission of a packet stream 
containing the refresh-header packet and the header -compressed packet to the 
receiver node. 

Brief Summary Text (38) : 

The refresh header can be a full header including the content of the original 
header of the non -compressed packet. The refresh header also may be another format. 
For example, in the situation in which the first packet transmitted to the receiver 
node has initialized the compression state, the sender node may transmit a refresh 
header which is able to refresh the compression state based on the result of the 
previous initialization. 

Description Paragraph (6) : 

FIG. 5 is a format of the header of the Compressed non-TCP packet transmitted in 
the second embodiment of the present invention. 

Description Paragraph (10) : 

FIG. 7 shows a state of transition in the header compression process and 
reconstruction process by means of ROHC. 

Description Paragraph (18) : 

FIG. 12 shows a format of the IPv6 header used in the variation example of each of 
the embodiments. 

Description Paragraph (20) : 

FIG. 13B shows a content of the compressed header. 
Description Paragraph (28) : 

With reference to the accompanying drawings, embodiments of the present invention 
will now be described. The embodiments, which represent various modes of the 
present invention, do not mean to limit the scope of the present invention and can 
be modified within the scopes of the present invention. 

Description Paragraph (31) : 

FIG. 1 is a block diagram pictorially exemplifying a configuration of a 
communication system into which a packet transmitting method of the present 
invention can be applied. In the communication system, a transmitter data terminal 

1 and a receiver data terminal 2 are provided so as to exchange packets through a 
network 3 . The present invention is described hereinafter with reference to an 
example in which the transmitter terminal 1 sends packets to the receiver terminal 

2 . 

Description Paragraph (33) : 
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In this configuration, the transmitter data terminal 1 sends in sequence packets 
destined for the receiver data terminal 2 through the network 3 . A packet to be 
sent from the transmitter data terminal 1 is an IP packet including RTP/UDP/IP 
headers shown in FIG. 13A. The relay apparatus on the sender node 3a receives in 
order IP packets sent from the transmitter data terminal 1, converts the received 
IP packets into either full -header packets including a full header or header^ 
compressed packets including a compressed header, and sends them to the receiver 
node 3b. As described before, the full header is a header in which a length value 
contained in an IP header or UDP header of RTP /UDP/IP headers of an IP packet is 
replaced by data including a C0NTEXT_ID or link_seq. On the other hand, when 
receiving the header - compressed packet or full -header packet transmitted from the 
sender node 3a, the relay apparatus on the receiver node 3b restores the RTP/UDP/IP 
headers from the compressed -header of the header - compressed packet or the full 
header of the full-header packet, and sends an IP packet including the RTP/UDP/IP 
headers to the receiver data terminal 2. The receiver data terminal 2 receives an 
IP packet sent from the receiver node 3b and performs predetermined processing (for 
example, display of images, replay of sound, or the like in accordance with an RTP 
payload) according to the received IP packet. 

Description Paragraph (34) : 

Like the conventional technique described before, the full header packet means a 
packet enabling to restore an IP packet including RTP/UDP/IP headers on the basis 
of only contents of the full header included in the full-header packet. The length 
values included in the RTP/UDP/IP headers are replaced by a CONTEXT_S TATE and 
link_seq, however, the length values can be restored with reference to the 
information on lower layers as well. In contrast, the header - compressed packet 
means a packet that can be decompressed to an IP packet based on other packets 
(such as full -header packet) , and cannot be decompressed to an IP packet including 
RTP/UDP/TP headers based only on the compressed header included in the header^ 
compressed packet. 

Description Paragraph (37) : 

A control* portion 33a is a means or unit for controlling each of the receiving 
portion 31a, . the transmitting portion 32a and the storage portion 34a. Practically, 
the control portion 33a implements the following processes described in item a and 
b. 

Description Paragraph (39) : 

The relay apparatus provided on the sender node in the related art described above 
was configured so that the relay apparatus converted the packet with the static 
field in the header changed, the packet selected every specific fixed numbers, or 
the packet to be transmitted immediately after receiving C0NTEXT_STATE from the 
receiver node, into a full -header packet without compressing the header of the 
packet and transmitted the full -header packet to the receiver node. On the 
contrary, the relay apparatus provided on the sender node 3a of the present 
embodiment is configured so that the relay apparatus receives IP packets sent from 
the transmitter data terminal 1, and converts the IP packets whose data is 
important (hereinafter referred to as an "important packet") into a full -header 
packet without compressing the header, and transmits the full-header packet to the 
receiver node 3b. Here, the important packet means the packet including the data 
which serves important role when the receiver data terminal 2 replays the audio or 
displays images. More specifically, the important packet means the packet including 
the data remarkably affecting the quality of the audio or image (for example, 
deteriorating the quality of the image displayed or music replayed) at the receiver 
data terminal 2 when the packet is lost. The control portion 33a at the sender node 
3a decides that the received IP packet is important in the following cases 
described hereunder. 

Description Paragraph (40) : 

{circle around (1)} IP Packet with the Marker Bit M in the RTP Header Set or the 
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Next Packet to the IP Packet with a Marker Bit M Set 
Description Paragraph (41) : 

The marker bit M is contained in the RTP header in the IP packet transmitted from 
the transmitter date terminal 1. The control portion 33a in the sender node 3a 
decides importance of the IP packet by examining the marker bit. The detail thereof 
is described hereunder. 

Description Paragraph (42) : 

In the case where the data transmitted from the transmitter data terminal 1 is 
video data including several frames, the first data of each frame usually contains 
very useful information for displaying the images. On the other hand, the marker 
bit M in the RTP header is generally set in the packet containing the last data of 
a video frame. The next packet of the packet with the marker bit M in the RTP 
header set is usually the first data of a video frame. Accordingly, the control 
portion 33a in the sender node 3a is configured so that the next packet of the 
packet with the marker bit M in the RTP header set is decided to be the important 
packet . 

Description Paragraph (43) : 

In addition, there are cases in which the marker bit M in the RTP header may be set 
when the payload contains some configuration information, e.g., the data structure 
or the like. On the other hand, the packet containing the configuration information 
serves important role when in the receiver data terminal uses the data to display 
the images or replay music. Accordingly, the control portion 33a in the sender node 
3a may be configured so that a packet with the marker bit M in the RTP header set 
is decided to be an important packet. 

Description Paragraph (44) : 

{circle around (2) } Cases Where the Timestamp in the RTP Header is Changed 
Description Paragraph (47) : 

When the payloads of IP packets transmitted from the transmitter data terminal 1 
are audio data including talkspurts and silence portions, the size of the packets 
including the data talkspurts is in general larger than the size of the packet 

containing the of silence portions. Wher^the packe t r^^^ t\±jcl£%~*4\a— » 

talkspu rts is not correctly received in the receiver data ...termi n al 2, the quality 
of the audTo~is rem arkably deteri orated, compared with th e case when the packet 
^ containing the data oT~1TiTe nce porti ons is not correct lv^r eceiy ed. Accordingly, 
wEen the da ta^Tn^tKe^P" packet transTrnTEleci""f ronPthe transmitter data terminal 1 is 
audio data, the control portion 33a at the sender node 3a examines whether the 
payload of each packet is the data of talkspurts or the data of silence portions in 
accordance with the size of the IP packet, and decides that the packet containing 
the data of talkspurts, namely the packet having the size larger than the 
prescribed size, is the important packet. 

Description Paragraph (4 9) : 

When the payloads of IP packets transmitted from the transmitter data terminal 1 
are audio data including talkspurts and silence, the receiver data terminal 2 needs 
to recognize the switch from talkspurts to silence, and the switch from silence to 
talkspurts. The control portion 33a at the sender node 3a therefore converts the 
packet immediately after the switch from silence to talkspurts or the switch from 
talkspurts to silence into a full -header packet without compressing the header and 
transmits the full-header packet to the receiver node 3b. Practically, the control 
portion 33a at the sender node 3a examines whether the size of the IP packet is 
larger than the prescribed size (constant value) or not whenever receiving the IP 
packet, and decides that the IP packet received this time is the important packet 
in the case when the packet received previous time has a smaller size than the 
prescribed size, and simultaneously the packet received this time has a larger size 
than the prescribed size. Similarly, the packet received this time is decided to be 
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the important packet in the case when the packet received previous time has a 
larger size than the prescribed size, and simultaneously the packet received this 
time has a smaller size than the prescribed size. 

Description Paragraph (52) : 

b. Generating and Transmitting a Header - compressed Packet and a Full -header Packet 
Description Paragraph (53) : 

The control portion 33a at the sender node 3a outputs the first packet and the IP 
packet decided to be the important packet within the IP packets received from the 
transmitter data terminal 1 as a full -header packet to the transmitting portion 
32a, while outputting the remaining packets as a header -compressed packet to the 
transmitting portion 32a. 

Description Paragraph (55) : 

On the other hand, for the IP packet to be transmitted as a header -compressed 
packet, the control portion 3 3a produces the compressed header based on the content 
of the IP packet stored in the storage portion 34a (refer to FIG. 13B) ) in the same 
manner as described in the conventional art, and sends the header - compressed packet 
containing the compressed header to the transmitting portion 32a. 

Description Paragraph (57) : 

The relay apparatus on the receiver node 3b has the same structure as those of the 
sender node 3a. More specifically, the relay apparatus on the receiver node 3b 
includes the receiving portion 31b for receiving the packet from the sender node 
3a, the control portion 33b for controlling each portion in the receiver node 3b, 
the storage portion 34b and a transmitting portion 32b for transmitting the packet 
outputted from the control portion 33b to the receiver data terminal 2. However, 
the control portion 33b at the receiver node 3b converts the full -header packet or 
the header - compressed packet transmitted from the sender node 3a into the IP packet 
and outputs to the transmitting portion 32b, contrary to the control portion 33a at 
the sender node 3a described above. 

Description Paragraph (59): 

Then, the practical operation carried out between the relay apparatuses on the 
sender node 3a and the receiver node 3b is described with reference to FIG. 3. In 
FIG. 3, the case is assumed where the video data containing several frames is 
transmitted from the transmitter data terminal 1. Practically, the packets al to a5 
are IP packets containing the data of the frame A. The packets bl to b5 are IP 
packets containing the data of the frame B. The packets cl to c5 are IP packets 
containing- the data of the frame C. In addition, for the convenience to explain, as 
described in {circle around (1)} above, it is assumed hereunder that only the IP 
packet containing the first data of each frame is decided to be the important 
packet . 

Description Paragraph (61) : 

Then, when receiving the IP packet a2 from the transmitter data terminal 1, the 
control portion 33a in the sender node 3a examines whether or not the marker bit M 
in the RTP header is set. In this case, since the IP packet a2 is* not the last 
packet of the frame A, the marker bit M is not set. Then, the control portion 33a 
converts the RTP/UDP/IP header in the IP packet a2 into the compressed header based 
on the content in the full header of the packet al retained in the storage portion 
34a, and sends the header - compressed packet a2 to the receiver node 3b. Hereafter, 
the control portion 33a at the sender node 3a conducts the same process in relation 
to the packets a3 and a4 . 

Description Paragrap h (62) : 

Then, when receiving the packet a5 from the transmitter data terminal 1, the 
control portion decides whether the marker bit M in the RTP header is set or not. 
In this case, since the IP packet a5 is the last packet of the frame A, the marker 
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bit M is set. Accordingly, the control portion 33a decides that the IP packet 
received next to the packet a5 is the important packet. As for the IP packet a5, 
the control portion converts the RTP/UDP/IP header in the IP packet into the 
compressed header and sends to the receiver node 3b in the same manner as described 
in relation to the IP packets a2 to a4 . 

Description Paragraph (63): 

Then, the control portion 33a receives the IP packet bl . In this case, since it is 
clear v that the IP packet bl is the important packet (i.e., the IP packet bl is the 
* f irst packet of new frame B) because the maker bit M in the IP packet a5 is set, 
the control portion 33a converts the RTP/UDP/IP header of the packet bl into the 
full header, and writes the content of the full header into the storage portion 
34a, and then, sends the full -header packet bl containing the full header to the 
receiver node 3b. As for the IP packets b2 to b5 received afterward, the control 
portion sends them as header -compressed packets to the receiver node 3b in the same 
manner as described above in relation to the IP packets a2 to a5 . 

Description Paragraph (65) : 

Then, the control portion 33b at the receiver node 3b restores the compressed 
header in the header -compressed packet a2 received through the receiving portion 
31b, based on the content of the RTP/UDP/IP header in the IP packet al retained in 
the storage portion 34b, and sends it as the IP packet containing the RTP/UDP/IP 
header to the receiver data terminal 2. As for the packet a3 received next, the 
control portion 3 3b in the receiver node 3b restores the IP packet, and then sends 
it to the receiver data terminal 2 in the same manner as described above. 

Description Paragraph (66) : 

On the other hand, the example as shown in FIG. 3 exemplifies the case in which the 
header -compressed packet a4 transmitted from the sender node 3a is lost before 
reaching the receiver node for some reason. In this case, the receiver node 3b 
detects that the packet a4 is lost by the fact that the link sequence number in the 
compressed packet a5 to be received next is not in sequence. Since the header^ 
compressed packet a5 cannot be correctly restored unless the content of the header^ 
compressed packet a4 is referred to, the control portion 33b in the receiver node 
3b discards the packet received until the next full-header packet, i.e., the packet 
a5 is received. On the contrary, the packet bl containing the first data of the 
frame B is not discarded like the packet a5 due to the loss of the packet a4, since 
the packet bl is sent as the full-header packet. 

Description Paragraph (67) : 

As described above, in the packet transmitting method of the embodiment, the sender 
node 3a sends the important packet as the full -header packet to the receiver node 
3b. Accordingly, even in the case where the packet transmitted from the sender node 
is lost for some reason, and the header -compressed packet thereafter is discarded 
due to the loss, the important packet is sent to the receiver data terminal 2 as 
far as the important packet itself is not lost between the sender node 3a and the 
receiver node 3b. More specifically, the important packet to display the images (or 
replay audio) is not discarded at the receiver node 3b due to the lost of the other 
packets. Therefore, the degree of the influence of the packet loss on the quality 
of the images at the receiver data terminal can be lowered (for example, the 
deterioration of the quality of the image displayed or the audio replayed) , in 
comparison with the case in which the full -header packet is sent to the receiver 
node without considering whether or not the packet is the important packet, as 
described in the conventional art. 

Description Paragraph (68) : 

In the above, although there is described the case in which the IP packet next to 
the IP packet with the marker bit in the RTP header set, i.e., the IP packet 
containing the first data of the frame, is decided to be the important packet, the 
same operation as described above is applied to the case in which the other IP 



http://jupiter:9000/bin/gate.exe?f^doc&state=jnktgg.25. 1 &ESNAME=KWIC&p_Messag... 1 0/1 1/2006 



Record Display Form 



Page 11 of 18 



packet, namely the IP packets as shown in {circle around (2) } to {circle around 
(5)} described above are decided to be the important packets. 

Description Paragraph (74) : 

In the case described above in which only the important packet is transmitted as 
the full-header packet, the intervals to send the full-header packets becomes 
longer when the number of the important packets to be transmitted is fewer in 
comparison with the number of the other packets. In this case, it may be considered 
that a lot of header -compressed packets received until the next full -header packet 
is received are discarded due to the loss of the header -compressed packet. In order 
to avoid the above situation, it may be configured so that when the prescribed time 
T has passed without receiving the important packet after sending the full -header 
packet F (in other words, without sending the full-header packet), the packet to be 
transmitted next is sent as the full -header packet F even, if the packet is not the 
important packet, as shown in FIG. 4A. Alternatively, it may be configured so that 
when a specific number N of header -compressed packets are sent without receiving 
the important packet after sending the full -header packet F, the packet is sent as 
the full-header packet F regardless of the importance of the packet to be 
transmitted next . 

Description Paragraph (75) : 

Furthermore, it can be configured so that the relay apparatus on the sender node 
converts a non - compressed packet into the full -header packet F and transmits the 
full -header packet to the receiver node even if the non - compressed packet is not 
the important packet, every time when a specific number N of packets are 
transmitted or packets ranging for a specific period of time T are transmitted, as 
shown in FIG. 4B. 

Description Paragraph (82) : 

a. In the case in which the packet transmission is implemented to send video data 
obtained by an animated image compression coding algorithm containing an intra - 
frame coding process and an inter-frames prediction coding process (for example, 
the animated image coding algorithm corresponding to MPEG (Moving Picture Experts 
Group) ) , the IP packet containing the data obtained by the intra-f rame coding 
process (namely, the coded data of the I frame) is assigned to be the important 
packet. The reason thereof is that unless the I frame is properly restored in the 
receiver, the following frames with the inter- frames prediction coding implemented 
with reference to the I frame are not properly restored, b. In the case in which 
the packet transmission is implemented to send a layered coded data composed of the 
data of the base layer and the data of the enhanced layer, the IP packet containing 
the data of the base layer is assigned to be the important packet. The data of the 
base layer means the data which is highly important to restore the original 
information when the layered coded data is decoded at the receiver. In addition, 
the data of the enhanced layer means the data which is not so important as the data 
of the base layer, but serves to improve the quality of reproduction of the 
original information when it is properly decoded. For example, in the animated 
image compression coding algorithm in compliant with MPEG-2, a series of frames to 
be transmitted are divided into I frame, P frame and B frame. The intra-f rame 
coding is implemented to the I frame. A unidirectional inter-frames prediction is 
implemented to the P frame with reference to the preceding I frame or P frame. A 
bidirectional inter- frames prediction coding is implemented to the B frame with 
reference to the I frame or P frame flowing before and after thereof. In this case, 
the coded data of the I frame and P frame are the data of the base layer, and the 
coded data of the B frame is the data of the enhanced layer. The decoder can 
reproduce the animated image, although a time resolution thereof is low, as far as 
at least the data of the base layer is correctly received. Thus, the data of the 
base layer is important so that the data of the base layer is transmitted as the 
important packet. When the data of the enhanced layer is decoded at the decoder, 
the B frame is used to compensate the time gap between the I frame and P frame, 
thus improving the time resolution of the animated image. B. Second Embodiment 
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Description Paragraph (83) : 

It is configured in the above first embodiment that the relay apparatus provided on 
the sender node 3a has a function to convert the IP packet into the header^ 
compressed packet or the full -header packet (hereinafter referred to as a 
" compression function"), while the relay apparatus provided on the receiver node 3b 
has a function to convert the header - compressed packet or the full -header packet 
into the IP packet (hereinafter referred to as a "decompression function") . 
Contrary to the above, it is configured in the present embodiment that the 
transmitter data terminal and the receiver node 3b depicted in FIG. 1 have the 
compression function, while the sender node 3a and the receiver data terminal 2 
have the decompression function. 

Description Paragraph (84) : 

Practically, the receiver data terminal 1 produces in sequence the IP packet to be 
transmitted, and then, decides whether each of the IP packets is the important 
packet or not in the same manner as the first embodiment. The transmitter data 
terminal 1 sends the IP packet decided to be the important packet as the full- 
header packet to the sender node 3a, while the transmitter data terminal 1 sends 
the remaining packets as the header -compressed packet to the sender node 3a. 

Description Paragraph (85) : 

On the other hand, the relay apparatus provided on the sender node 3a converts the 
received header -compressed packet or the full -header packet into the IP packet and 
sends it to the receiver node 3b. Furthermore, the relay apparatus on the receiver 
node 3b decides whether each of the received IP packets from the sender node 3a is 
the important packet or not, and sends the IP packet decided to be the important 
packet as the full-header packet to the receiver data terminal 2, while sending the 
remaining IP packet as the header - compressed packet to the receiver data terminal 
2. The receiver data terminal 2 restores the IP packet on the basis of the received 
full -header packet or the header - compressed packet from the receiver node 3b, and 
then displays the images or replays the audio or the like in accordance with the 
data contained in each of the packets. The same effect as in the first embodiment 
can be obtained in the above configuration. 

Description Paragraph (87) : 

Also in this embodiment, the transmitter may be configured to consider, as the 
packet to be transmitted as the full header packet, not only the important packet, 
but also the IP packet with the static field changed as described in the variation 
example of the first embodiment (variation example 1) , the IP packet to be 
transmitted after passing a specific period without sending the IP packet or the 
full-header packet which is intended to be transmitted after transmitting a fixed 
number of the header - compressed packet without sending the full -header packet 
(variation example 2) , and the IP packet to be transmitted after receiving the 
CONTEXT_STATE from the sender node 3a. 

Description Paragraph (89) : 

As in the case of the embodiments described above, this embodiment supposes that 
the packet is transmitted by means of the non-TCP protocol such as UDP . RFC2507 
defined the compressed non-TCP header having the format shown in FIG. 5 as the 
compressed header which can be used for non-TCP packets. There are cases in which 
the fields for ID of IP and RTP in the header of the non-TCP packet are changed 
packet by packet. The compressed non-TCP header contains the fields composed of 
those fields having data which could be changed packet by packet. For convenience, 
the field thus contained in the compressed non-TCP header will be referred to as a 
"replace field." ID of IP and RTP shown in FIG. 5 are respectively the replace 
fields. Each compressed non-TCP header is generated with reference to a full header 
prior thereto. CID shown in FIG. 5 is the information identifying the full header 
which is referred to for generating the compressed non-TCP header. The "generation" 
is the field which is updated when a change is made in the constant fields of the 
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full header. 

Description Paragraph (90) : 

When receiving a compressed non-TCP header sent from the sender node, the 
communication apparatus on the receiver node refers to the compressed non-TCP 
header as well as the full header- which is identified by CID contained in the 
compressed non-TCP header, and generates a header having the replace fields of the 
compressed non-TCP header and the other fields of the full header. The 
communication apparatus then uses the generated header for processing the non-TCP 
packet . 

Description Paragraph (92) : 

The foregoing is the outline of the header compression method for non-TCP packets 
proposed in RFC2507. 

Description Paragraph (93) : 

The present embodiment is that the present invention is applied to the above- 
mentioned header compression method for the non-TCP packets. FIGS . 6B and 6C show 

examples of the packet transmission method of the present embodiment, respectively. 



Description Paragraph (94) : 

In the transmission method as shown in FIG. 6B, when the important packet is 
transmitted, a refresh-header packet RHP including the compressed non-TCP header 
instead of the full header is transmitted. The compressed non-TCP header includes 
all information necessary for recovering from the synchronization loss. Therefore, 
the same effect as those of the first embodiment is obtained even if the compressed 
non-TCP header is transmitted instead of the full header. 

Description Paragraph (98) : 

There is another header compression method of the IP packet, R0HC (Robust Header. 
Compression ) , issued as an Internet-Draft. This embodiment relates to the method of 
the packet compression and transmission using the ROHC method. 

Description Paragraph (99): 

In the first to third embodiments already described, the full header containing the 
content of the original header is transmitted at the time of starting the packet 
delivery and during the packet delivery, as a refresh header to recover the 
synchronization at the receiver. In the method of the packet compression and 
transmission using the ROHC, a refresh header with the format other than the full 
header is transmitted from the transmitter and the synchronization is recovered at 
the receiver. Hereunder, the outline of the ROHC is described to help understanding 
of the technical signification of the present embodiment. 

Description Paragraph (100) : 

FIG. 7 shows a transition of the compression state used in the ROHC. As depicted in 
the drawing, the ROHC has three kinds of the compression states. 

Description Paragraph (101) : 

When the packet* delivery accompanying the header compression is carried out between 
the sender node and the receiver node, the compression process and reconstructing 
process are started from the initialization state in the sender node and the 
receiver node. Furthermore, when the synchronization loss occurs during the packet 
transmission and reception, the compression process and the reconstruction process 
have to return to the initialization state, in order to recover the synchronization 
between the sender node and the receiver node. When a certain condition is 
satisfied, after the compression process and the reconstruction process are 
initialized, the state of the compression process at the sender node and the state 
of the reconstruction process at the receiver node are transferred to- the 
difference value changing state which is the further upper state. When a certain 
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condition is satisfied in this state, the processing states of the compression and . 
reconstruction are transferred to the difference value constant state which is the 
further upper state. As the processing states of the compression and reconstruction 
are transitioned to the upper state, the size of the compressed header to be 
transmitted becomes smaller. 

Description Paragraph (103) : 

The IR header is produced from the IP/UPP /RTP header of the first packet in order 
to initialize the compression process and the reconstruction process, when the 
packet delivery using the header compression starts. In FIG. 8A, the Static Chain 
consists of the information of the Static field which is not changed packet by 
packet in the IP/UDP /RTP header . The Dynamic chain consists of the information of 
the Dynamic field which can be changed packet by packet in the IP/UDP /RTP header . 

Description Paragraph (104) : 

The IR-DYN header is produced at the time when the synchronization loss occurs 

during the packet delivery and the initialization of the reconstructing process of 

the header is required at the receiver, after the header compression is already 
started, and sent to the receiver. The IR-DYN header contains only the Dynamic 

chain, as depicted in FIG. 8B. Since the Dynamic chain includes all the information 

of the Dynamic field, the synchronization is recovered by the reception thereof at 
the receiver node. 

Description Paragraph (105) : 

Both the IR header and the IR-DYN header contain CRC computed from the original 
IP/UDP /RTP header . The node receiving the IR header and the IR-DYN header can 
examine whether each header is properly restored or not by the use of the CRC. 

1 

Description Paragraph (106) : 1 
The communication apparatus on the sender node monitors, between the packets, the \ 
difference of the Dynamic field of the IP/UDP /RTP header for the packets to be I 
transmitted in order. When there is no change in the difference (namely, difference ] 
value constant state) , the header - compressed packet containing Type-0 as depicted 
in FIG. 9A is produced and transmitted to the receiver node. In FIG. 9A, SN 
represents the sequence number of the RTP . The receiver node learns that there is 
no change in difference of the Dynamic field between the packets, when receiving 
the Type-0 header. Then, only the difference available by that time in the Dynamic 
field is added to the present value thereof to reconstruct the Dynamic field. 

Description Paragraph (107) : 

When the communication apparatus on the sender node recognizes the change in the 
difference (namely, difference value changing state) , the communication apparatus 
on the sender node produces the header -compressed packet containing Type-1 header 
or Type-2 header to transfer the new difference to the receiver node, and transmits 
it to the receiver node. The format of the Type-1 header is depicted in FIG. 9B, 
and the format of the Type-2 header is depicted in FIG. 9C. In those drawings, SN 
represents information relating to the difference in RTP sequence number, and TS 
represents information relating to the difference in RTP timestamp. It is arbitrary 
that which one of the Type-1 header or the Type-2 header is transmitted. 

Description Paragraph (108) : 

The information relating to the difference mentioned above is obtained by LSB 
(Least Significant Bit) coding of the corresponding field. FIG. 10 shows the steps 
of the LSB coding. 

Description Paragraph (109) : 

In this method, when the difference in some field of header between the packets is 
changed, one or more packets prior to the packet to be compressed are selected as 
reference packets. It is arbitrary that which packets are selected as th e reference 
packets. The field of header of the packet to be compressed and the corresponding 
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fie lcL of he ade r ^o f the reference pac ket: t. frus s je^ex:±jejdL-ar^^ 

and then tKe^tJITferent lower bits are transmitted. In the example depicted in FIG. 
10, since the lower four bits are different^ the lower four bits are transmitted to 
the receiver node by the Type-1 header or the Type-2 header. In the receiver node, 
the lower four bits in the corresponding field of the header of the reference 
packet are replaced by the data of the lower four bits in the Type-1 header or the 
Type-2 header, thus the original field can be reconstructed. 

Description Paragraph (112) : 

In the present embodiment, when the important packet is transmitted, the IP/UDP /RTP 
header of the important packet is converted into either one of the IR header, the 
IR-DYN header, the Type-1 header or the Type-2 header, and the refresh-header 
packet containing the header thus converted is transmitted to the receiver node. 
More detailed description will be given as follows: 

Description Paragraph (113) : 

In the header compressed packet transmission according to ROHC, there are cases in 
which when the header is received by the communication apparatus on the receiver 
node and the content of the header is correctly restored, the ACK is transmitted 
from the receiver node to notify the sender node of the matter. In the present 
embodiment, when the important packet to be transmitted is generated after 
receiving such an ACK from the receiver node, the Type-1 header or the Type-2 
header is generated from the IP/UDP /RTP header of the important packet with 
reference to the earlier header which has already been transmitted and 
acknowledged. The refresh header packet containing the Type-1 or Type-2 header thus 
generated is then transmitted to the receiver node. The Type-1 or Type-2 header 
thus transmitted contains the data indicating the difference between the Dynamic 
field in the IP/UDP /RTP header of the important packet and that of the acknowledged 
packet for which the ACK has already been received by sender node. 

Description Paragrap h (115) : 

There are cases in which when the important packet is transmitted, but there is no 
header which has already been sent and acknowledged. In such cases, the IR header 
or the IR-DYN header is generated from the IP/UDP /RTP header of the important . 
packet and the refresh-header packet containing it is transmitted to the receiver 
node . ■ 



Description Paragraph (118) : \ 
Each of the above embodiments described above discloses the packet transmitting i 
method applied to the transmission of the IPv4 packet. However, the applicable 
scope of the present invention is not limited to the above. The present invention 
can be applied to the transmission of the IPv6 packet. FIG. 12 shows the format of 
IPv6 header. As shown in the drawing, The IPv6 has the STATIC field which is not 
changed between the packets, the DYNAMIC fields which may be changed between the 
packets, and the Eliminated field which has a known value or can be reconstructed 
from other field. Accordingly, the packet transmitting method described in each of 
the embodiments or the variations thereof can be applied to the non - compressed y 
packet having the IP/UDP /RTP header in which the IP portion consists of the IPv6 / 
header. y 

Other Reference Publication (1) : 

Jonsson L.E. et al, "RObust Checksum-based header compression (ROCCO) , " Internet 
Article, Jan. 18, 2000. cited by other 

Other Reference Publication (2) : 

Degermark M et al . , "RFC 2507: IP Header Compression. " Internet Article, Feb. 1999. 
cited by other 

Other Reference Publication (3) : 

Casner S. et al . , "RFC 2508 : Compressing IP/UDP /RTP Headers for Low-Speed Serial 
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Links," Internet Article, Feb. 28, 1999. cited by other 
CLAIMS : 

1. A packet transmitting method for transmitting packets from a sender node to a 
receiver node through a network, comprising the steps of: determining by a 
communication apparatus provided at the sender node, whether each non - compressed 
packet to be transmitted is an important packet, on the basis of a header, a 
timestamp, or size of each non - compressed packet; converting by the communication 
apparatus provided at the sender node, each non -compressed packet which is 
determined to be an important packet into a refresh-header packet, the refresh- 
header packet including a refresh header, the refresh header including enough 
information to recover synchronization in the receiver node; and transmitting a 
packet stream containing the refresh-header packet and a header - compressed packet 
to the receiver node, the header - compressed packet including a compressed header, 
the compressed header including less information than the refresh header. 

2. The packet transmitting method of claim 1, wherein the refresh header is a full 
header containing a content of an original header included in the non - compressed 
packet . 

4. The packet transmitting method of claim 1, wherein the refresh header is a 
header produced with reference to a header which has already been transmitted to 
the receiver node and acknowledged by the receiver node. 

5. The packet transmitting method of claim 1, wherein the communication apparatus 
at the sender node determines whether each one of the non - compressed packets is an 
important packet, on the basis of a condition of marker bits of real-time transport 
protocol headers included in the non -compressed packets . 

6. The packet transmitting method of claim 5, wherein a non - compressed packet is 
determined as the important packet when a non - compressed packet transmitted 
immediately prior to the non - comp re s s ed packet has the marker bit set. 

7. The packet transmitting method of claim 5, wherein a non - compressed packet is 
determined as the important packet when the non -compressed packet has the marker 
bit set. 

8. The packet transmitting method of claim 1, wherein the communication apparatus 
at the sender node determines whether each one of the non - compressed packets to be 
transmitted is an important packet, on the basis of packet sizes of the non^ 
compressed packets. 

9. The packet transmitting method of claim 8, wherein a non - compressed packet is 
determined as the important packet when the non - compressed packet has a larger size 
than a predetermined size. 

10. The packet transmitting method of claim 8, wherein a non -compressed packet is 
determined as the important packet when the non - compressed packet has a larger size 
than a predetermined size and the next non -compressed header has a smaller size 
than a predetermined size or when the non - compressed packet has a smaller size than 
the predetermined size and the next non - compressed header has a larger size than 
the predetermined size. 

11. The packet transmitting method of claim 1, wherein a non - compressed packet is 
determined to be an important packet when the non - compressed packet contains 
configuration information which is referred to in order to interpret data in the 
packet in the receiver node. 

13. The packet transmitting method of claim 12, wherein a non - compressed packet is 
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determined as the first packet of the frame when the non - compressed packet contains 
a timestamp different from a timestamp contained in a preceding non -compressed 
packet. 

14. The packet transmitting method of claim 1, wherein data in each of the packets 
represents a voice, and a non - comp r e s s ed packet is determined to be an important 
packet when the non - compressed packet contains data representing a voice portion. 

15. The packet transmitting method of claim 14, wherein the non -compressed packet 
containing data representing the voice portion is obtained on a basis of a change 
in packet size of a set of non -compressed packets to be transmitted. 

16. The packet transmitting method of claim 1, wherein: data in each of the packets 
comprises at least a part of coded data representing image for several frames 
obtained by means of an algorithm containing intra-frame coding process and inter- 
frames prediction coding process, and a non - compressed packet is determined to be 
an important packet when the non - compr e s s ed packet comprises a packet containing a 
coded data obtained by the intra-frame coding process. 

17. The packet transmitting method of claim 1, wherein: data in each of the packets 
comprises at least part of a layered coded data consisting of data in a base layer 
and data in an enhanced layer, and a non -compressed packet is determined to be an 
important packet when the non - compressed packet comprises a packet containing the 
data in said base layer. 

18. The packet transmitting method of claim 1, wherein the communication apparatus 
at the sender node converts a non -compressed packet into a full -header packet even 
if the non -compressed packet is not an important packet, when a prescribed time has 
passed or a prescribed number of compressed-header packets has been transmitted 
after transmission of a last full-header packet. 

21. The packet transmitting method of claim 1, wherein the communication apparatus 
at the sender node transmits a non -compressed packet to be transmitted as a 
refresh-header packet, in response to a request from the receiver node. 

22. A program for causing a computer to execute a packet transmitting method for 
transmitting packets from a sender node to a receiver node through a network, the 
method comprising the steps of : determining by a communication apparatus provided 
at the sender node, whether each non -compressed packet to be transmitted is an 
important packet, on the basis of a header, a timestamp, or size of each of the 
non - compressed packets; converting by a communication apparatus provided at the 
sender node, each non -compressed packet which is determined to be an important 
packet into a refresh-header packet, the refresh-header packet including a refresh 
header, the refresh header including enough information to recover synchronization 
in the receiver node; and transmitting a packet stream containing the refresh- 
header packet and the header -compressed packet to the receiver node, a header^ 
compressed packet including a compressed header, the compressed header including 
less information than the refresh header. 

23 . A computer readable storage media for storing a program which makes a computer 
execute a packet transmitting method for transmitting packets from a sender node to 
a receiver node through a network, the method comprising the steps of: determining 
by a communication apparatus provided at the sender node, whether each non^ 
compressed packet to be transmitted is an important packet, on the basis of a 
header, a timestamp, or size of each of the non -compressed packets; converting by 
the communication apparatus provided at the sender node, each non - compressed packet 
which is determined to be an important packet into a refresh-header packet, the 
refresh-header packet including a refresh header, the refresh header including 
enough information to recover synchronization in the receiver node; and 
transmitting a packet stream containing the refresh-header packet and a header^ 



http://jupiter:9000/bin/gate.exe?f=doc&state=jnktgg.25 . 1 &ESNAME=KWIC&p_Messag. . . 10/11 /2006 



Record Display Form 



Page 18 of 18 



compressed packet to the receiver node, the header -compressed packet including a 
compressed header, the compressed header including less information than the 
refresh header. 

24. A relay apparatus provided in a network for receiving packets from a sender 
node of the network and transmitting the packets to a receiver node of the network, 
the relay apparatus comprising: a determining unit that determines whether each 
non - compr e s s ed packet to be transmitted is an important packet, on the basis of a 
header, a timestamp or size of each of the non -compressed packet; a compresser that 
converts each non -compressed packet which is determined to be an important packet 
into a refresh-header- packet , the refresh-header packet including a refresh header, 
the refresh header including enough information to recover synchronization in the 
receiver node; and a transmitter that transmits a packet stream containing the 
refresh-header packet and a header -compressed packet to the receiver node, the 
header -compressed packet including a compressed header, the compressed header 
including less information than the refresh header. 

25. A data terminal comprising: a determining unit that determines whether a non^ 
compressed packet to be transmitted is an important packet, on the basis of a 
header, a timestamp or size of the non - c ompre s s ed packet; a compresser that 
converts each non - compressed packet which is determined to be an important packet 
into a refresh-header packet, the refresh-header packet including a refresh header, 
the refresh header including enough information to recover synchronization in a 
receiver node; and a transmitter that transmits a packet stream containing the 
refresh header packet and the header -compressed packet to the receiver node, a 
header - compressed packet including a compressed header, the compressed header 
including less information than the refresh header. 
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An implementation of a technology, described herein, for transmitting compressed 
network transport -layer -protocol headers in a speedy, efficient, inf erentially 
synchronized, and robust manner. An implementation, described herein, models the 
transmission of compressed headers to the congestion procedure of the network 
transport -layer protocol (e.g., TCP's). Doing so, the sender of the compressed 
headers can infer whether the receiver correctly received them. Unlike the slow 
direct synchronization employed by conventional schemes, this implementation of the 
present claimed invention inf erentially synchronizes by modeling after the 
congestion procedure of the network transport -layer protocol. This is inherently 
faster than direct synchronization. Since the implementation performs well over 
both noiseless and noisy links, it is particularly suited to use over wireless 
communications channels. This abstract itself is not intended to limit the scope of 
this patent. The scope of the present invention is pointed out in the appending 
claims. 
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aspect of the present invention uses the knowledge of the structure and content of 
communication protocols to form a static dictionary or static binary code tree. As 
a result, the compression efficiency can be greatly increased. Another aspect of 
the present invention provides a combined static and dynamic dictionary or binary 
code tree to perform communication protocol compression. In one aspect of the 
invention, the static binary code tree or static dictionary is constructed by 
studying flows of data protocols in the -conditions of their intended usage. 
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ABSTRACT : 

In packet communications that utilize header compression/decompression, relatively- 
fast and reliable header compression context updates can be accomplished with 
relatively low overhead by: sending anticipatory context update requests before 
decompressor context invalidation is detected; sending redundant context update 
requests; and sending redundant context updates. Transmission parameters associated 
with both context update requests and context updates can be controlled 
appropriately to improve their chances for delivery, and needless context update 
requests can be identified and ignored at the header compression side. 
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ABSTRACT : 

A method, system, and apparatus for increasing the efficiency and robustness of the 
compression of a communication protocol for communication between entities over 
bandwidth limited communication links. The. present invention uses the request-reply 
nature of communication protocols to update compression and decompression 
dictionaries. Each communication entity will update its dictionary with a new 
message as soon as it is known that the other communication entity has access to 
the message. In one aspect of the present invention, an entity updates a 
compression/decompression dictionary by updating the dictionary with sent messages 
as soon as a reply arrives from the other entity, and by updating the dictionary 
with received messages immediately. In another aspect of the present invention, 
received messages are used to update an entity's decompression dictionary and sent 
messages are used to update an entity's compression dictionary. 
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entities over bandwidth- limited communication links. In one aspect of the present 
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